Many Command/Response busses employ a bus controller to initiate communications between a controller and remote terminals connected to the bus, and between the remote terminals themselves. Examples of a command/response bus include the MIL-STD-1553 (and variants) and MIL-STD-1773 busses. These example command/response bus types may be employed for digital, command/response, and time division multiplexing designed for avionics data busses. The MIL-STD-1553 bus uses electrical signaling and the MIL-STD-1773 bus uses optical signaling. Nearly all mission essential subsystems on a military aircraft communicate with one another over one of these two types of busses. Each of these subsystems may come from different sources (manufacturers)—some more trustworthy than others—and each of the components that make up each subsystem may also come from individual sources that may or may not be trustworthy. Subsystems on shared data busses may “see and hear” everything that goes on between every other subsystem and the bus. Subsystems connect to the MIL-STD-1553 bus through a standard two-conductor connector (analogously, to a MIL-STD-1773 bus through a fiber optic coupler) that may allow them to listen in on communications of unrelated subsystems and may allow them to jam the bus either intentionally or unintentionally. Subsystems may be faulty when installed, develop faults after installation, or may be maliciously engineered to allow for remote access and control through, for example, Radio Frequency (RF) channels. It is also possible for one subsystem to reset another by acting temporarily as a bus master. MIL-STD-1553 and MIL-STD-1773 busses are deployed on a multitude of systems such as, for example, aircraft systems, missile systems, ground vehicles systems, supervisory and data acquisition (SCADA) systems, and space systems.
The bus may be considered the nervous system of the vehicle with few, if any, safeguards because it is possible that subsystems may listen in on communications of unrelated subsystems and may also jam the bus either intentionally or unintentionally. It is also possible for one subsystem to reset another by acting temporarily as a bus master. Therefore, there is a need to protect communications over Command/Response busses to mitigate these risks.
With regard to relevant prior art, U.S. Pat. No. 9,582,447, Arehart et al., teach prior art on protecting MIL-STD-1553, but it achieves similar goals through dissimilar means. Arehart et al. teach means to modify the topology of the bus network to protect end-point remote terminals in the system. Specifically, they teach the introduction of a switch that replaces the shared common data bus with a series of point-to-point connections or they introduce a similar capability into the bus controller to create a Bus Controller Processor and Memory (BCPM) that similarly replaces the shared common bus. Further, Arehart et al describe bus monitoring, which in general is already common in MIL-STD-1553 implementations, Arehart, et al. require an additional port for communications from the monitor to the BCPM. Still further, while Arehart, et al. describe how monitors may communicate to the BCPM over a dedicated communication path, they do not teach a means to extract logged data via other means. Finally, Arehart, et al. do not teach a means of initializing the system when the addresses and other metadata of the guarded remote terminal or subsystem is unknown.